「AI 都已經能自動生成測試了，還需要學 TDD 嗎？」
這大概是我這幾年被問過最多次的問題之一。表面上聽起來很合理：以前寫測試要花時間，現在跟 AI coding agent 說一句「幫這支函式補測試」，幾秒鐘後一堆測試案例就跑出來了，全部綠燈。既然產出測試的成本被壓到接近零，TDD 那套「先寫測試、再寫實作、再重構」的紀律，是不是也跟著過時了？
我想先講一個場景。假設你請 AI 幫一支既有函式補測試，它動作很快，幾秒鐘後回報「已完成，10 個測試案例，全部通過」。你打開測試檔案掃一眼，斷言看起來都合理，覆蓋率報告也顯示這支函式被覆蓋到 95% 以上。看起來是一次漂亮的產出。
但如果你回頭問一句：「這些測試在驗證什麼業務規則？如果我把這支函式的核心邏輯改錯，這些測試會不會抓到？」——很多時候答案是不會。測試裡斷言的可能只是「函式回傳了某個型別」「陣列長度是 3」，跟這支函式實際該做的事情沒有直接關係。測試套件是綠的，但它沒有在保護任何東西。
這不是 AI 能力不夠，而是它在做一件跟人類寫測試時不太一樣的事：它被要求「產生會通過的測試」，而不是「產生能驗證正確行為、並且在行為壞掉時會失敗的測試」。這兩件事聽起來很像，結果可能完全不同。
這正是我想在這個系列裡談的核心問題：AI 可以加速 Red-Green-Refactor 循環的每一步，但「這個測試值不值得留、覆蓋夠不夠、重構要不要做」這些品質判斷，不能交給 AI 自己決定。
這句話會貫穿接下來 30 天。每一篇文章，不管講的是測試命名、Mock 濫用、覆蓋率迷思還是任務拆解，最終都會回到這一句上。
讀完這篇，你會：
TDD（Test-Driven Development，測試驅動開發）的核心是 Red-Green-Refactor 三個步驟：先寫一個會失敗的測試（Red），寫最少的程式碼讓它通過（Green），再在測試保護下改善程式碼結構（Refactor）。這套流程從被提出到現在已經行之有年，本質上沒有因為 AI 出現而改變。
真正改變的是「產出測試」這件事的成本結構。以前寫測試很花時間，這個時間成本本身會逼工程師去想：這個測試真的有必要嗎？我是不是可以只測最關鍵的行為？現在這個成本被壓低了，AI 可以一次生成一整批測試案例，代價是這批測試案例的「品質篩選」這一步，如果沒有人主動去做，就不會有人做。
這裡要區分兩件事：
一是測試的產出速度。這件事 AI 確實幫得上忙，寫測試骨架、補邊界案例、產生測試資料，這些機械性的工作交給 AI 可以省下大量時間。
二是測試的品質判斷。一個測試該不該留下來，取決於它是不是真的在驗證一個有意義的行為，是不是會在程式碼壞掉時真正失敗，覆蓋率數字背後有沒有對應到實際的業務邏輯分支。這件事需要判斷「這支程式碼該做什麼」跟「什麼情況算是壞掉」，而這個判斷來自對系統行為的理解，不是單純的模式匹配。
問題在於，這兩件事很容易被混在一起看待。一個團隊看到「AI 生成的測試全部通過、覆蓋率提升到 90%」，很自然會覺得品質也跟著提升了。但速度加快跟品質把關是兩條不同的軸線，前者被 AI 大幅拉高，後者如果沒有人主動介入，其實完全沒有跟著提升，甚至可能因為測試數量暴增而更難被人工複查。
這就是我認為 AI 時代反而更需要 TDD 紀律的原因：TDD 從來不只是「有沒有寫測試」，而是一套逼你在每個步驟上做判斷的流程——先看到紅燈，確認測試真的會因為行為缺失而失敗；用最小手段讓測試變綠，確認你理解這個測試在檢驗什麼；最後才在測試保護下重構。當寫測試的動作被自動化之後，如果沒有人刻意把這幾個判斷點找回來，整套流程很容易退化成「叫 AI 產生一批綠燈測試」，跟 TDD 原本要達成的目的完全脫節。
這個系列會反覆用到三個判斷，作為衡量「這個測試套件值不值得信任」的標準：
留不留：這個測試案例是不是在驗證一個真實存在、有意義的行為？如果把它刪掉，會不會有任何一種程式碼錯誤變得測不出來？如果答案是不會，這個測試就只是在製造覆蓋率數字，不是在提供保護。
夠不夠：目前的測試套件涵蓋了正常路徑（happy path），但邊界情況、例外情況、輸入不合法的情況呢？AI 在沒有被明確要求的情況下，傾向只覆蓋看得到的正常流程，邊界情境往往要靠人主動點出來才會補上。
做不做：程式碼已經在測試保護下能動了，接下來要不要重構？重構會改善可讀性和可維護性，但也有成本跟風險。這個「值不值得現在做」的判斷，取決於對這段程式碼未來會被怎麼使用、改動頻率高不高的理解，這不是單純看程式碼本身的結構就能決定的事。
這三個判斷有一個共同點：它們都需要對「這支程式碼實際上該做什麼」有理解，而不只是對「這段程式碼寫了什麼」做描述。AI 擅長的是後者——它能很精準地根據現有程式碼反推出對應的測試斷言。但前者需要的是對業務意圖、系統邊界、未來變動方向的判斷，這些資訊往往不在程式碼本身裡，而是在需求、在團隊的共同理解裡。
下面用一個簡化的例子說明差異。假設有一支函式，負責根據會員的消費金額計算折扣。
❌ 只要求「幫這支函式寫測試」，AI 傾向產生的結果：
function calculateDiscount(amount) {
if (amount >= 1000) return amount * 0.9;
return amount;
}
test('calculateDiscount returns a number', () => {
const result = calculateDiscount(1500);
expect(typeof result).toBe('number');
});
test('calculateDiscount with 1500', () => {
expect(calculateDiscount(1500)).toBe(1350);
});
第一個測試斷言「回傳值是 number 型別」，這種斷言幾乎不可能因為邏輯錯誤而失敗——就算折扣算錯了，回傳的還是一個數字。它通過了，但沒有驗證任何有意義的行為，是典型的「留不留」該被淘汰的案例。
✅ 明確要求「測試要能反映折扣規則，並涵蓋邊界」之後，比較值得留下的版本：
test('金額達到門檻時套用九折', () => {
expect(calculateDiscount(1500)).toBe(1350);
});
test('金額剛好等於門檻時仍套用九折', () => {
expect(calculateDiscount(1000)).toBe(900);
});
test('金額低於門檻時不打折', () => {
expect(calculateDiscount(999)).toBe(999);
});
test('金額為零時不打折且不噴錯', () => {
expect(calculateDiscount(0)).toBe(0);
});
這一版每個測試都對應到一條實際的業務規則，而且刻意涵蓋了門檻值本身（1000）跟門檻值前一格（999），這是最容易藏 bug 的邊界。如果有人把 >= 誤改成 >，第二個測試會立刻抓到。這才是測試該提供的保護力。
兩個版本表面上都是「AI 生成的測試」，差別在於有沒有人在中間插入「這個測試在驗證什麼」的判斷。AI 兩種版本都寫得出來，差別在於人有沒有明確要求、以及事後有沒有審視測試本身的意義。
測試綠燈只證明程式碼跟測試彼此一致，不證明這個一致的行為就是對的。
接下來 30 天分成四大部：
第一部（Day 1-7）談「為什麼 AI 時代更需要 TDD」，會拆解 Red-Green-Refactor 每個階段在 AI 協作下容易被跳過的地方，先建立問題意識。
第二部（Day 8-16）聚焦「AI 寫測試最容易犯的錯」，包括硬編碼、過度 Mock、只測 happy path 這些常見陷阱，搭配具體案例說明。
第三部（Day 17-23）進到「怎麼讓 AI 遵守 TDD 循環」的具體做法，包括覆蓋率迷思、Test Double 的選擇、以及怎麼把大任務拆解成可以逐步紅綠重構的小步驟。
第四部（Day 24-30）是實戰案例與總結，把前面三部的原則收斂成一套可以帶回自己專案使用的判斷框架。
回想你最近一次請 AI coding agent 幫忙寫或補測試的經驗：那些測試案例裡，有幾個是你事後真的驗證過「如果邏輯改錯了，這個測試會失敗」？如果答案是「沒有仔細確認過」，這可能是這個系列對你最有用的起點。
在深入討論 AI 帶來的各種陷阱之前，先花一天把地基打好：Day 02 會快速複習 Red-Green-Refactor 三步驟的本質，確認我們對「什麼是 TDD」有共同的起點，再往下談 AI 介入之後每個步驟會發生什麼變化。
延伸閱讀：本次鐵人賽同時並行的其他四個系列，會從不同角度處理相關的經驗，有興趣可以一起追：
iThome鐵人賽
看影片追技術